Skip to content

Conversation

@ruspl-afed
Copy link
Contributor

Currently null is tolerated as a callback for a number of terminal-related operations. The introduced empty implementation NOOP allows to prohibit null as a callback argument.

@github-actions
Copy link
Contributor

github-actions bot commented Jul 16, 2025

Test Results

 1 947 files  ±0   1 947 suites  ±0   1h 30m 39s ⏱️ - 6m 26s
 4 720 tests ±0   4 696 ✅ ±0   24 💤 ±0  0 ❌ ±0 
14 160 runs  ±0  13 993 ✅ ±0  167 💤 ±0  0 ❌ ±0 

Results for commit 00f2335. ± Comparison against base commit cbe2947.

♻️ This comment has been updated with latest results.

@ruspl-afed ruspl-afed changed the title Empty implementation for Done callback to stop accepting null Replace Done callback with CompletableFuture result Jul 16, 2025
@ruspl-afed ruspl-afed changed the title Replace Done callback with CompletableFuture result Replace Done callback with CompletableFuture result Jul 16, 2025
Copy link
Contributor

@laeubi laeubi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@laeubi may be we should return IStatus here to simplify caller's life?

I think a CF is better to reflect the async nature of this, but using IStatus at all seems questionable to me. an anonymous CompletableFuture<?> that simply is failed on any error seems more appropriate.. if we feel to pass a status a CoreException can then be used.

@ruspl-afed ruspl-afed force-pushed the done_null_to_none branch 2 times, most recently from 5361f03 to 09863d2 Compare July 16, 2025 10:19
@ruspl-afed
Copy link
Contributor Author

Now the snippet is @laeubi

		try {
			delegate.execute(properties);
		} catch (Exception e) {
			throw new ExecutionException(e.getMessage(), e);
                        //or log
		}

Currently `null` is tolerated as a callback for a number of
terminal-related operations. Moreover, it seems that callers prefer to
avoid any callback.
Replace rarely used callback with completable future result.
Copy link
Contributor

@laeubi laeubi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine for me now

@ruspl-afed ruspl-afed merged commit 8e520e1 into eclipse-platform:master Jul 16, 2025
20 of 22 checks passed
@ruspl-afed ruspl-afed deleted the done_null_to_none branch July 16, 2025 12:55
Comment on lines +197 to +201
if (runnable.isExecuteAsync()) {
return CompletableFuture.supplyAsync(() -> runnable.run(tvid, title, connector, data),
Display.getDefault());
} else {
try {
Display display = PlatformUI.getWorkbench().getDisplay();
display.asyncExec(() -> runnable.run(tvid, title, connector, data, done));
} catch (Exception e) {
// if display is disposed, silently ignore.
}
return CompletableFuture.completedFuture(runnable.run(tvid, title, connector, data));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that effectively both of the branches of this if statement run the runnable immediately instead of queuing it on the display queue.

See #2155 (comment)

and Display.execute(Runnable) which is used by asyncSupplyStage. When Display.execute is called on the UI thread, then the runnable is run immediately.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When Display.execute is called on the UI thread, then the runnable is run immediately.

That's indeed the case... I think one can simply pass in display::asyncExec as the executor to get the desired effect as before.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants